<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Terminology</title>
    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
    <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
    <link rel="up" href="transapp.html" title="Chapter 12.  Berkeley DB Transactional Data Store Applications" />
    <link rel="prev" href="transapp_why.html" title="Why transactions?" />
    <link rel="next" href="transapp_fail.html" title="Handling failure in Transactional Data Store applications" />
  </head>
  <body>
    <div xmlns="" class="navheader">
      <div class="libver">
        <p>Library Version 12.1.6.2</p>
      </div>
      <table width="100%" summary="Navigation header">
        <tr>
          <th colspan="3" align="center">Terminology</th>
        </tr>
        <tr>
          <td width="20%" align="left"><a accesskey="p" href="transapp_why.html">Prev</a> </td>
          <th width="60%" align="center">Chapter 12.  Berkeley DB Transactional Data Store Applications </th>
          <td width="20%" align="right"> <a accesskey="n" href="transapp_fail.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="transapp_term"></a>Terminology</h2>
          </div>
        </div>
      </div>
      <p>
        Here are some definitions that will be helpful in
        understanding transactions:
    </p>
      <div class="variablelist">
        <dl>
          <dt>
            <span class="term">Thread of control</span>
          </dt>
          <dd>
                Berkeley DB is indifferent to the type or style
                of threads being used by the application; or, for that
                matter, if threads are being used at all —
                because Berkeley DB supports multiprocess access. In
                the Berkeley DB documentation, any time we refer to a
                <span class="emphasis"><em>thread of control</em></span>, it can be
                read as a true thread (one of many in an application's
                address space) or a process.
            </dd>
          <dt>
            <span class="term">Free-threaded</span>
          </dt>
          <dd>
                A Berkeley DB handle that can be used by
                multiple threads simultaneously without any
                application-level synchronization is called
                <span class="emphasis"><em>free-threaded</em></span>.
            </dd>
          <dt>
            <span class="term">Transaction</span>
          </dt>
          <dd>
                A <span class="emphasis"><em>transaction</em></span> is a one or
                more operations on one or more databases that should
                be treated as a single unit of work. For example,
                changes to a set of databases, in which either all of
                the changes must be applied to the database(s) or none
                of them should. Applications specify when each
                transaction starts, what database operations are
                included in it, and when it ends.
            </dd>
          <dt>
            <span class="term">Transaction abort/commit</span>
          </dt>
          <dd>
                Every transaction ends by
                <span class="emphasis"><em>committing</em></span> or
                <span class="emphasis"><em>aborting</em></span>. If a transaction
                commits, Berkeley DB guarantees that any database
                changes included in the transaction will never be
                lost, even after system or application failure. If a
                transaction aborts, or is uncommitted when the system
                or application fails, then the changes involved will
                never appear in the database.
            </dd>
          <dt>
            <span class="term">System or application failure</span>
          </dt>
          <dd><span class="emphasis"><em>System or application
                failure</em></span> is the phrase we use to
                describe something bad happening near your data. It
                can be an application dumping core, being interrupted
                by a signal, the disk filling up, or the entire system
                crashing. In any case, for whatever reason, the
                application can no longer make forward progress, and
                its databases are left in an unknown state.
            </dd>
          <dt>
            <span class="term">Recovery</span>
          </dt>
          <dd><span class="emphasis"><em>Recovery</em></span> is what makes the
                database consistent after a system or application
                failure. The recovery process includes review of log
                files and databases to ensure that the changes from
                each committed transaction appear in the database, and
                that no changes from an unfinished (or aborted)
                transaction do. Whenever system or application failure
                occurs, applications must usually run
                recovery.
            </dd>
          <dt>
            <span class="term">Deadlock</span>
          </dt>
          <dd><span class="emphasis"><em>Deadlock</em></span>, in its simplest
                form, happens when one thread of control owns resource
                A, but needs resource B; while another thread of
                control owns resource B, but needs resource A. Neither
                thread of control can make progress, and so one has to
                give up and release all its resources, at which time
                the remaining thread of control can make forward
                progress.
            </dd>
        </dl>
      </div>
    </div>
    <div class="navfooter">
      <hr />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="transapp_why.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="transapp.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="transapp_fail.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">Why transactions? </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> Handling failure in Transactional Data Store applications</td>
        </tr>
      </table>
    </div>
  </body>
</html>
